Wir freuen uns, heute die Verfügbarkeit von NGINX Open Source 1.15.2 bekannt geben zu können. Eine wichtige Neuerung in dieser Version ist die neue Variable „$ssl_preread_protocol“, mit der Sie beim Weiterleiten von Datenverkehr über einen TCP-Proxy (stream) zwischen SSL/TLS und anderen Protokollen unterscheiden können. Dies ist hilfreich, wenn Sie Firewall-Beschränkungen umgehen möchten, indem Sie beispielsweise SSL/TLS- und SSH-Dienste über denselben Port betreiben.
Die neue Funktion wird mit der kommenden Version NGINX Plus R16 auch für Kunden von NGINX Plus verfügbar sein.
When and How to Use $ssl_preread_protocol
Wenn Sie SSL/TLS-Datenverkehr mit den Modulen http oder stream terminieren und entschlüsseln, erfasst die Variable $ssl_protocol (http, stream) die vom Client verwendete SSL- oder TLS-Version. Manchmal möchten Sie SSL/TLS-Datenverkehr jedoch lediglich weiterleiten, ohne ihn zu entschlüsseln, und dazu mit den stream-Modulen einen einfachen TCP-Proxy oder Load-Balancer implementieren.
Das Modul stream_ssl_preread untersucht die anfängliche ClientHello-Nachricht in einer SSL- oder TLS-Verbindung und extrahiert mehrere Werte, die zur Verwaltung der Verbindung verwendet werden können. Die mit Version 1.15.2 hinzugefügte Variable $ssl_preread_protocol erfasst die neueste SSL/TLS-Versionsnummer aus dem Feld client_version der ClientHello-Nachricht. Wenn die Erweiterung supported_versions in der ClientHello-Nachricht vorhanden ist, wird die Variable auf TLSv1.3 gesetzt.
Wenn eine Verbindung keine SSL- oder TLS-Version verwendet, bleibt die Variable „$ssl_preread_protocol“ leer. Dies weist darauf hin, dass die Verbindung ein anderes Protokoll als SSL/TLS verwendet, beispielsweise SSH.
Das folgende Konfigurationsbeispiel verwendet die Variable $ssl_preread_protocol in einem map-Block, um die Variable $upstream auf den Namen der Upstream-Gruppe festzulegen, die für das von der Verbindung verwendete Protokoll geeignet ist. Die Direktive proxy_pass leitet die Anfrage anschließend an die ausgewählte Upstream-Gruppe weiter. Beachten Sie, dass die Direktive ssl_preread on im server-Block enthalten sein muss, damit die Variable $ssl_preread_protocol funktioniert.
stream { upstream ssh {
server 192.0.2.1:22;
}
upstream web {
server 192.0.2.2:443;
}
map $ssl_preread_protocol $upstream {
default ssh;
"TLSv1.2" web;
}
# SSH and SSL on the same port
server {
listen 443;
proxy_pass $upstream;
ssl_preread on;
}
}Damit die Konfiguration wirksam wird, müssen Clients statt über den Standardport 22 über Port 443 auf den SSH-Server zugreifen. Mit dem integrierten SSH-Client unter macOS und Linux können Sie beispielsweise mit der Option -p den Port ändern:
$ ssh ssh-server-ip-address -p 443So erhalten Sie die neueste NGINX-Version
Die neueste Version von NGINX ist stets im Mainline-Zweig unseres offiziellen Repositorys verfügbar.
Mehr erfahren
NGINX Open Source 1.15.2 enthält weitere Verbesserungen und Fehlerbehebungen. Eine vollständige Liste der Neuerungen finden Sie im NGINX-Änderungsprotokoll.
Über den Autor

Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.